Subject: Re: Comments/Questions on STUN, Request for submissions

From: [email-masked] (David Matusow)
Date: Tue, 13 Jul 93 15:24:42 -0400

>   From: alan bartky <[email-masked]>
>   X-Mailer: SCO System V Mail (version 3.2)
>   To: [email-masked]
>   Subject: Comments/Questions on STUN, Request for submissions
>   Date: Tue, 13 Jul 93 11:00:33 PDT
>   
>   Having read Wayne Clark's contribution on STUN I have the following comments
>   It looks like a much simpler protocol as far as handling SDLC to SDLC 
>   connections across an IP network, using TCP as an error corrected sequenced
>   protocol so that SDLC can be locally acknowledged (so you don't have to
>   poll through the network).  

One problem that I don't remember seeing discussion about is what occurs
if a message cannot be delivered across TCP to the destination.  As
an RR has already occurred, how can this be "backed up" to provide
recovery at the higher layers?  TCP can't always guarantee that a message
can be delivered, yet the local RR has acknowledged the message.

I would hope that taking down the connection is not required, but
I'm not sure how else to recover from this error.

David Matusow
Hypercom

---

From: [email-masked]
Date: Tue, 13 Jul 93 12:56:35 PDT

>I'm not sure how else to recover from this error.

    Part #1:
	If you look at a multiprotocol network with the same orientation
	of say an APPN/ISR network, then the problem of "premature"
	acknowledgement of I-Frames (via the Nr count) is endemic to both.
	It's the nature of hop-by-hop routing.

	SNA applications can still operate over networks with this property
	because they always use definite-response-required protocols
	(i.e. RQD* in the RH) at critical points in the dialogue (e.g.
	Start Print in the WCC for a printer, RQD1 for LU-level handshake,
	RQD2|3 for CONFIRM, etc.).  If things get backed up, then the
	I-Frames carrying the PIUs with this particular RH setting gets
	backed up.  So the data from the application's perspective is
	intact.

    Part #2:
	If TCP can't deliver data from A to B, then there is no way to get
	to B.  Once network convergence fails, TCP sessions drop (router
	dependent :-), buffered data gets tossed (including potential
	PIUs with RQD* RHs in them), and the DLC connections using those
	TCP sessions get torn down.

	The dropped DLC connections trigger session outage notification on
	the end systems and it is the end system's responsibility to
	recover at a higher level:  requeue the print job, resource
	failure - retry for the LU 6.2 application, etc.

    That is my view of it.  TCP isn't perfect but that's what we're working
    with.

Wayne